home *** CD-ROM | disk | FTP | other *** search
/ QRZ! Ham Radio 3 / QRZ Ham Radio Callsign Database - Volume 3.iso / digests / tcp / 930009.txt < prev    next >
Internet Message Format  |  1994-06-04  |  21KB
  1. Date: Sat,  9 Jan 93 04:30:14 PST
  2. From: Advanced Amateur Radio Networking Group <tcp-group@ucsd.edu>
  3. Errors-To: TCP-Group-Errors@UCSD.Edu
  4. Reply-To: TCP-Group@UCSD.Edu
  5. Precedence: Bulk
  6. Subject: TCP-Group Digest V93 #9
  7. To: tcp-group-digest
  8.  
  9.  
  10. TCP-Group Digest            Sat,  9 Jan 93       Volume 93 : Issue    9
  11.  
  12. Today's Topics:
  13.                             8086 compiles
  14.                       CPU ID test code (2 msgs)
  15.                           DPMI mode (2 msgs)
  16.                      MID dups problem - Revisited
  17.                               NNTP usage
  18.                            NOS under Minix
  19.                       PMNOS 1D NOT AT CHOWDANET
  20.                              PMNOS V1.0D
  21.                          Thanks. info wampes
  22.                               TNOS info
  23.                             Unwanted mail
  24.                             update TCPCMD
  25.                              V40 machine
  26.                            WHAT IS SMACK ?
  27.                        WNOS-Group server Back.
  28.                                 xspawn
  29.                           XSPAWN - once more
  30.  
  31. Send Replies or notes for publication to: <TCP-Group@UCSD.Edu>.
  32. Subscription requests to <TCP-Group-REQUEST@UCSD.Edu>.
  33. Problems you can't solve otherwise to brian@ucsd.edu.
  34.  
  35. Archives of past issues of the TCP-Group Digest are available
  36. (by FTP only) from UCSD.Edu in directory "mailarchives".
  37.  
  38. We trust that readers are intelligent enough to realize that all text
  39. herein consists of personal comments and does not represent the official
  40. policies or positions of any party.  Your mileage may vary.  So there.
  41. ----------------------------------------------------------------------
  42.  
  43. Date: Fri, 8 Jan 93 10:40:42 MST
  44. From: Larsen Karl VAL-C 678-3145 <klarsen@wsmr-emh73.army.mil>
  45. Subject: 8086 compiles
  46. To: tcp-group@ucsd.edu
  47.  
  48.  Before there is any problem, I have an 8086 lap-top that I run
  49. nos in so I at least will need a copy of nos that is compiled for that
  50. cpu. So I will do this: As I get the source codes for the latest
  51. versions of nos I will compile an 8086 version and place it on UCSD and
  52. tomcat. 
  53.  
  54.  If I have a problem I will yell here for support.
  55.  
  56. 73, karl k5di@k5di.nm.usa.na
  57.  
  58. ------------------------------
  59.  
  60. Date: Fri, 8 Jan 93 19:21:36 PST
  61. From: "Jerzy Tarasiuk" <JT@zfja-gate.fuw.edu.pl>
  62. Subject: CPU ID test code
  63. To: MIKEBW@ids.net (Mike Bilow, <MIKEBW@ids.net>)
  64.  
  65. > Date:    Thu, 7 Jan 1993 16:55:07 -0500 (EST)
  66. > Message-Id: <930107165507.3ec7@ids.net>
  67. >
  68. > The main objective for my CPU test program right now is so obvious that
  69. > you didn't think of it!  If there is going to be a 386-specific version
  70. > on NOS, it has to at least produce and intelligible error message if
  71. > someone tries to run it on an XT or 80286.  This is a user support issue.
  72. > If the program isn't smart enough to quit gracefully on a machine that
  73. > can't run it, it will most likely just lock up.
  74.  
  75. Right (however I know about commercial product (operating system),
  76. dedicated for 80386 which didn't have CPU type check in it).
  77.  
  78. But probably it cannot be coded into C program: to test it I compiled
  79. CPU test program (just your program translated to C I sent to tcp-group)
  80. with -2 option (I have BC 3.0 only, it doesn't have -3 option) and tried
  81. to run (using machine code debugger, of course) - and I found first
  82. opcode of main() is ENTER, which is not valid 8088 opcode and would
  83. cause crash if executed. Can write main() in assembly (code to verify
  84. CPU followed by JMP C_main or so), but we cannot be absolutely sure
  85. library routines executed before main() use valid 8088 opcodes only
  86. (trying to run my program I had a little hope the startup code of .EXE
  87. made with -2 option checks on what CPU it runs).
  88.  
  89. Other ways: modify .EXE to put extra startup code in it (similar way
  90. many viruses do it: append new code on end, put old transfer address
  91. in the new code, change module size and transfer address in header;
  92. it requires the .EXE to contain no overlays);
  93. or link extra startup code (this needs put name of startup routine
  94. in the code added, need know it and may be compiler-dependent; this
  95. also causes the CPU check code to remain in memory all time).
  96.  
  97. > It would be nice if my CPU test program eventually can be used to run
  98. > one version of NOS which will automatically select 386 or generic
  99. > instructions, but the performance penalty would probably be too high
  100.  
  101. Performance loss is during loading the program only: need select what
  102. is to be loaded. But this means either 2 copies of program to be on
  103. disk (one for 8088, second for better CPU) or the loading program must
  104. be smart enough to select what parts are to be loaded (this would need
  105. something like diff, but for executable files, to prepare data for it;
  106. a lot of work and don't know if can get any positive effect; note to
  107. build executable need compile all modules for both modes, for what
  108. reason, I suppose no one is changing CPU in his computer every day).
  109. First concept is more sensible: a program can be named NOS.COM, it
  110. should check what CPU it runs on, say it is 286, then is searches the
  111. directory it was loaded from, say it founds NOS.EX3 (for 80386) and
  112. NOS.EX1 (for 80188 or better), it should say no NOS.EX2 was found
  113. (for user to know what is best for his computer) and load NOS.EX1.
  114. This (or program setting exit code dependent on CPU + batch using the
  115. code to select proper command) can be good for LAN where most programs
  116. are on network disks and there are different machines using them.
  117. And it doesn't require to modify anything in NOS sources.
  118.  
  119. 73's, JT
  120.  
  121. ------------------------------
  122.  
  123. Date: Fri, 8 Jan 1993 16:04:08 -0500 (EST)
  124. From: MIKEBW@ids.net (Mike Bilow, <MIKEBW@ids.net>)
  125. Subject: CPU ID test code
  126. To: tcp-group@ucsd.edu
  127.  
  128. From: IDS::MIKEBW       "Mike Bilow, <mikebw@ids.net>"  8-JAN-1993 15:53:32.36
  129. To: SMTP%"JT@zfja-gate.fuw.edu.pl"
  130. CC: MIKEBW
  131. Subj: Re: CPU ID test code
  132.  
  133. I didn't realize that BC++ would put an ENTER instruction at the beginning
  134. of main() if the "-3" compiler switch was used.  That's a problem.  I will
  135. look into the c0.asm module that comes with BC++; it may be possible to
  136. use a reserved name for my CPU test routine and have it executed before
  137. main().  Modifying c0.asm is not something I would want to do, although
  138. it would obviously fix this problem.
  139.  
  140. Another thought I had was to wrap NET.EXE inside a small loader which
  141. tested the CPU and then transferred control to the program wrapped
  142. inside.  PKLITE, for example, works this way, and it is a lot more
  143. complicated.
  144.  
  145. It seems to me that it would have been a good idea for Borland to have
  146. included the CPU trap as a part of the "-3" switch.  It would be a nice
  147. feature as well with the "-2" switch.
  148.  
  149. -- Mike Bilow, <mikebw@ids.net>  (Internet)
  150.  
  151. ------------------------------
  152.  
  153. Date: Fri, 8 Jan 93 10:13:09 EST
  154. From: kz1f@RELAY.WESTBORO.LEGENT.COM
  155. Subject: DPMI mode
  156. To: tcp-group@ucsd.edu
  157.  
  158. Bruce Perens writes -
  159.         well, alot of good stuff abt linix (Unix lite).
  160. Oh, dare I start....
  161. Everything he said abt the pluses of Linix are also true for OS/2.
  162. The really good new is that the negatives he mentioned are not true
  163. for OS/2, ie:
  164.  No step learning curve since its cmd structure is almost identical to DOS
  165.  OS/2 does run existing DOS applications
  166.  OS/2 does run 99.999% of existing Windows applications.
  167.  
  168. NOS for OS/2 does exist, the GNU compiler is free etc.
  169. Well enough of my soap boxing, I simply couldnt resist. Walt
  170.  
  171. ------------------------------
  172.  
  173. Date: Fri, 8 Jan 1993 10:50:56 -0800 (PST)
  174. From: Bruce Perens <bruce@pixar.com>
  175. Subject: DPMI mode
  176. To: kz1f@legent.com
  177.  
  178. I guess the point I should be making is that those of us with 386 and
  179. higher class processors should be running more modern operating systems
  180. than DOS. Pre-emptive multiprocessing and protected virtual address
  181. spaces have been around for three decades. Programming multiple-client
  182. systems without them is possible, but perhaps more hassle than it is
  183. worth. 
  184.  
  185. I agree, OS/2 is a fine platform, and runs DOS and Windows applications,
  186. even those that do direct screen write. If you want to run DOS or
  187. Windows applications on the same system with NOS, OS/2 is your best
  188. platform today. Being a kernel hacker, I prefer a system where I can have
  189. the kernel source, but a supported commercial system is a better idea
  190. for most non-hackers.
  191.      Bruce Perens
  192.  
  193. On Fri, 8 Jan 1993 kz1f@RELAY.WESTBORO.LEGENT.COM wrote: 
  194.  
  195. > Bruce Perens writes -
  196. >         well, alot of good stuff abt linix (Unix lite).
  197. > Oh, dare I start....
  198. > Everything he said abt the pluses of Linix are also true for OS/2.
  199. > The really good new is that the negatives he mentioned are not true
  200. > for OS/2, ie:
  201. >  No step learning curve since its cmd structure is almost identical to DOS
  202. >  OS/2 does run existing DOS applications
  203. >  OS/2 does run 99.999% of existing Windows applications.
  204. > 
  205. > NOS for OS/2 does exist, the GNU compiler is free etc.
  206. > Well enough of my soap boxing, I simply couldnt resist. Walt
  207. > 
  208. > 
  209. > 
  210.  
  211. ------------------------------
  212.  
  213. Date: Fri, 8 Jan 93 19:24:40 PST
  214. From: Bill Healy <healy@moriah.ee.unr.edu>
  215. Subject: MID dups problem - Revisited
  216. To: tcp-group@ucsd.edu (tcp-group)
  217.  
  218. > Well, with a simple addition to the forward.c file of WG7J1.07b, the dup
  219. > MIDs problem is history! This is the snip of code I added to TNOS to
  220. > handle the problem. I've sent it to Johan, and he is adding it to JNOS.
  221. > The code changes the bid from $abcde_host.domain to $abcde%destinationuser.
  222.  
  223. What is abcde, the message number?
  224.  
  225. Bill N8KHN
  226.  
  227. ------------------------------
  228.  
  229. Date: Fri, 08 Jan 1993 09:58:09 CST
  230. From: ben@val.val.com (Ben Thornton)
  231. Subject: NNTP usage
  232. To: tcpgroup@ucsd.edu (TCP/IP Packet Radio Working Group)
  233.  
  234. Does anyone have any experiences using the NNTPS features of JNOS1.07?
  235.  
  236. One of the local IP stations and I decided to set up one of his machines
  237. as an NNTP server and we began posting test articles from my machine via
  238. radio link and from his machine via a SLIP connection.  What happened was
  239. that when I posted some articles on my machine and then kicked my NNTP
  240. client (I did it gently :-), it forwarded the articles to the server just fine,
  241. but when the other fellow kicked his client on his second machine, no new
  242. articles showed up on his local disk.  Am I missing something (other than the
  243. documentation)?
  244.  
  245.   Ben
  246.  
  247.  
  248. --
  249. Ben Thornton             packet:  wd5hls@wd5hls.ampr.org
  250. Video Associates Labs  Internet:  ben@val.com
  251. Austin, TX                 uucp:  ...!cs.utexas.edu!val!ben
  252. "Push to Test --->@    ...Release to Detonate"
  253.  
  254. ------------------------------
  255.  
  256. Date: Fri, 08 Jan 1993 14:02:01 est
  257. From: "Clayton Decosterd" <clay@drone.hazeltine.com>
  258. Subject: NOS under Minix
  259. To: tcp-group@ucsd.edu
  260.  
  261. Hi All,
  262.  
  263.   I have a copy of the Minix operating system for the PC. I would like 
  264. to know if anyone is running NOS with this operating system. Any
  265. info would be appreciated. 
  266.  
  267. Thanks 
  268.   73
  269. Clay KB2FUR
  270.  
  271. -- 
  272. Clayton DeCosterd      INTERNET  : clay @ drone.hazeltine.com
  273.                        COMPUSERVE: 71754,447
  274.  
  275. ------------------------------
  276.  
  277. Date: Fri, 8 Jan 1993 16:25:33 -0500 (EST)
  278. From: MIKEBW@ids.net (Mike Bilow, <MIKEBW@ids.net>)
  279. Subject: PMNOS 1D NOT AT CHOWDANET
  280. To: kz1f@legent.com, tcp-group@ucsd.edu
  281.  
  282. Walt's uploads of the new PMNOS 1D were trashed by the virus scanner at
  283. ChowdaNet.  By using the GNU ZIP tools, Walt would have created a slightly
  284. incompatible archive file.  In particular, GNU ZIP uses the new "deflate"
  285. compression algorithm that is in PKZIP only as of the beta versions.  The
  286. official version of DOS PKZIP that is used by the ChowdaNet virus scanner
  287. apparently didn't know what to do, reported an error code, and the files
  288. were treated like a corrupt ZIP file and trashed.
  289.  
  290. I can straighten this out, since I can bypass the virus scanner using
  291. sysop privleges.  (Walt could have bypassed the virus scanner himself
  292. just by using an extension other than "ZIP," but he didn't know.  Of
  293. course, any file named like that is handled manually by the susop.)
  294.  
  295. Until I can fix this when I have time to push 1.5 MB back and forth
  296. later tonight, DO NOT CALL CHOWDANET for PMNOS.  If all goes well, I
  297. should have things right by Saturday morning.
  298.  
  299. -- Mike Bilow, <mikebw@ids.net>  (Internet)
  300.  
  301. ------------------------------
  302.  
  303. Date: Fri, 8 Jan 93 10:53:51 EST
  304. From: kz1f@RELAY.WESTBORO.LEGENT.COM
  305. Subject: PMNOS V1.0D
  306. To: tcp-group@ucsd.edu
  307.  
  308. It is with great pride/relief that I am announcing the general availability of 
  309. PM NOS V1.0D. As I have mentioned earlier this most probably will be it for 
  310. PMNOS as you have all come to know it. Technology hasnt stopped and neither 
  311. have I. My next offerring, to be named later, will be based on an entirely 
  312. different technology, support SCC and i-net. Enough on futures. Through next 
  313. fri, PMNOS1DX (executable, intronos.inf and assorted readmes) as well as 
  314. PMNOS1DS (source) will be available via anonymous ftp from giskard.uthscsa.edu.
  315. After next fri these files will be availible at ucsd.edu. A couple of notes:
  316. You will need a recent (1.2 or 2.0) pkunzip or preferable the OS/2 32 bit GNU 
  317. unzip to unzip thes files. If you dont have this gem, its available at hobbes 
  318. and also probably watson.
  319. PMNOS now remembers, should you want it to forget, delete nos.ini from your 
  320. selected spool dir.
  321. The PMNOS1D? pair is also available from ChowdaNet (401)331-0304.
  322. Have fun, enjoy and BE SURE to read the readme.now file.
  323. Walt
  324.  
  325. ------------------------------
  326.  
  327. Date: Fri, 08 Jan 93 16:22:16 CET
  328. From: BARRY TITMARSH <BTITMARS%ESOC.BITNET@vm.gmd.de>
  329. Subject: Thanks. info wampes
  330. To: TCP-GROUP <TCP-GROUP@ucsd.edu>,
  331.  
  332. Thanks for the tip on wampes will look at the linux code later.
  333. Thanks. Barry
  334.  
  335. ------------------------------
  336.  
  337. Date: 08 Jan 1993 12:19:32 -0500 (EST)
  338. From: "Brian A. Lantz" <BRIANLANTZ@delphi.com>
  339. Subject: TNOS info
  340. To: tcp-group@ucsd.edu
  341.  
  342. Well, TNOS is not out yet, but it's not far away! A couple of quick code
  343. fixes and I'll be on to "minimal" documentation.
  344.  
  345. Several of you expressed interest in helping distribute the source/exe to
  346. several different locations. Thanks! If you can assist in getting it to the
  347. "masses", please send me a RF packet message (not Internet, please) in the
  348. following manner....
  349.  
  350.    To: REQSVR@KO4KS.#TPA.FL.USA.NA
  351.  Subj: Group Subscribe TNDIST
  352.  
  353. This will help me, by allowing my TNOS board to automate the mailing-list.
  354.  
  355. Also, I will be posting a "What else is in TNOS" message soon!
  356.  
  357.  
  358. 73 from Brian A. Lantz      KO4KS@KO4KS.#TPAFL.FL.USA.NA    3100813105
  359.                   Internet: brianlantz@delphi.com
  360.                    Amprnet: ko4ks@ko4ks.ampr.org         [44.98.0.167]
  361.  
  362. ------------------------------
  363.  
  364. Date: Fri, 8 Jan 1993 18:42:27 -0100 (GMT-1:00)
  365. From: andy@mimuw.edu.pl (Andrzej K. Brandt)
  366. Subject: Unwanted mail
  367. To: tcp-group@ucsd.edu
  368.  
  369. Hello there,
  370.  
  371. There is one thing in NOS that I really don't like and I wonder if there is any
  372. way to change that. It's the fact, that NOS accepts all mail addressed to host.
  373. I don't see any way to make him refuse mail to some "users" as grown up
  374. Internet hosts do.
  375.  
  376. The problem is, that I use address andy@sp5wca.ampr.org on 44-net, but others
  377. insist on mailing to sp5wca@sp5wca. This is not a big problem, it's just
  378. annoying. I dream about such a guy getting a nice <User uknown> returned
  379. letter. But it becomes more serious when we connect NOS to real Internet and
  380. someone makes an error in addressing, or for example replays to a public PC,
  381. from which many people send their mail via SMTP but only few receive it.
  382.  
  383. So - is there any possibility of changing that?
  384.  
  385. -- 
  386.  
  387.  
  388.                                73 de Andy SP5WCA
  389.  
  390.  
  391. /-------------------+--------+-------------------+-------------------------\
  392. I Andrzej K. Brandt I SP5WCA I andy@mimuw.edu.pl I sp5wca@sp5pbe.wa.pol.eu I 
  393. \-------------------+--------+-------------------+-------------------------/
  394.  
  395. ------------------------------
  396.  
  397. Date: Fri, 8 Jan 93 11:07:00 EST
  398. From: crompton@NADC.NAVY.MIL (D. Crompton)
  399. Subject: update TCPCMD
  400. To: tcp-group@ucsd.edu
  401.  
  402. I have placed a new tcpcmd.c at wg7j.ece.orst.edu's incoming. It
  403. addresses a few problems when using repeat.
  404.  
  405. 1. The 'tcp stat' - 't s' command listed all sockets even if they
  406.    were in listen state. When you have many servers going at once
  407.    as I do the screen can get very long - also when using repeat
  408.    a display CANNOT obviously be longer than a screen.
  409.  
  410. With the new code the 't s' command now does NOT display Listen sockets.
  411. Use 't s a' to display ALL sockets as usual.
  412.  
  413. 2. The 'tcp view bytes|timers', 't v t', 't v b' - command did not display
  414.    a banner if not sockets were displayed. This was fine for the normal
  415.    display but for repeat if no sockets were active nothing displays.
  416.    Also if just one socket was active and went away it stayed until
  417.    another became active.
  418.  
  419. In the new code a banner always displays.
  420.  
  421. I find the repeat code gives NOS a new dimension. It is really neat
  422. to see things change dynamically. Many thanks to Phil for the idea.
  423. On my 386sx switch at home I run a mono card, which is typically
  424. slower than current VGA. I find that the mono screen persistence
  425. couple with a repeat update of 500 (1/2 sec) works very nicely.
  426.  
  427. Doug
  428.  
  429. ------------------------------
  430.  
  431. Date: Fri, 8 Jan 93 17:18:30 PST
  432. From: "Jerzy Tarasiuk" <JT@zfja-gate.fuw.edu.pl>
  433. Subject: V40 machine
  434. To: n8fow@wsu.n8fow.ampr.org
  435.  
  436. > Date: Fri, 08 Jan 93 05:14:43 UTC
  437. > Message-Id: <5017@wsu.n8fow.ampr.org>
  438. > From: n8fow@wsu.n8fow.ampr.org
  439. >
  440. >      Actually I have a laptop here that has a V40 for it's CPU. There are
  441. > a couple plug-in boards for the PC that have V40 processors. The MIO board
  442. > is one and I believe it can run NOS for a standalone site.  I didn't enter
  443. > the cpu-id code, maybe someone can just post it somewhere to save time
  444. > (too busy with Borland C++ to remember debug :-)   and I can run it on
  445. > the V40 machine and see what it says.  I ran several programs about the
  446.  
  447. I have rewritten Mike's program in C (tried to compile it using BC 3.0,
  448. TC++ 1.01, MSC 6.0, TC 2.0, TC 1.5 - was working OK for every compiler).
  449. Here it is - run it and post results to Mike Bilow, <mikebw@ids.net>
  450.  
  451. char cpuid[]={
  452.  0x52,0x33,0xD2,0x9C,0x58,0x80,0xE4,0x0F,0x50,0x9D,0x9C,
  453.  0x58,0x80,0xE4,0xF0,0x80,0xFC,0xF0,0x74,0x12,0xFE,0xC2,
  454.  0x9C,0x58,0x80,0xCC,0xF0,0x50,0x9D,0x9C,0x58,0x80,0xE4,
  455.  0xF0,0x74,0x02,0xFE,0xC2,0xFE,0xC2,0x8B,0xC2,0x5A,0xCB},
  456.  *cpuname[]={"8088/8086/V20/V30\n","80286\n","80386/80486\n"};
  457.  
  458. main()
  459. {
  460.   int cpu,(far *CpuId)()=(int (far *)())cpuid;
  461.   cpu=(*CpuId)();
  462.   printf("\nProcessor detected: %s",cpuname[cpu-1]);
  463. }
  464.  
  465. 73's, JT
  466.  
  467. ------------------------------
  468.  
  469. Date: Fri, 08 Jan 93 20:53:05 CET
  470. From: BARRY TITMARSH <BTITMARS%ESOC.BITNET@vm.gmd.de>
  471. Subject: WHAT IS SMACK ?
  472. To: TCP-GROUP <TCP-GROUP@ucsd.edu>,
  473.  
  474. The subject line says it all.
  475. it seems to be in new netrom type or tnc type boxes
  476. some talk about it has been seen in Germany for past 6 months
  477. but i have never gotten a sensible reply for any one.
  478. Any Idears? Please
  479. Barry
  480.  
  481. ------------------------------
  482.  
  483. Date: Fri, 08 Jan 93 14:54:14 CET
  484. From: BARRY TITMARSH <BTITMARS%ESOC.BITNET@vm.gmd.de>
  485. Subject: WNOS-Group server Back.
  486. To: Packet Radio Digest <packet-radio@ucsd.edu>,
  487.  
  488. Hello.
  489. The Listserv@esoc.bitnet now again has its group server running again
  490. If you wish to be informed about WNOS specific bugs and software fixes
  491. then send a mail to the listserv@esoc.bitnet and use the SIGNON WNOS-GRP
  492. or simply help will get son info on how to do it.
  493. Thanks Barry List-Owner.
  494. New versions of WNOS - 5 out in the comming months.
  495.  
  496. ------------------------------
  497.  
  498. Date: Fri, 8 Jan 93 23:12:26 EST
  499. From: crompton@NADC.NADC.NAVY.MIL (D. Crompton)
  500. Subject: xspawn
  501. To: tcp-group@ucsd.edu
  502.  
  503.  
  504.  
  505. ------------------------------
  506.  
  507. Date: 08 Jan 1993 12:06:31 -0500 (EST)
  508. From: "Brian A. Lantz" <BRIANLANTZ@delphi.com>
  509. Subject: XSPAWN - once more
  510. To: tcp-group@ucsd.edu
  511.  
  512. After some more testing, I suggest changing the two lines in yesterday's
  513. XSPAWN fix in pc.c from
  514.  
  515.      addvect (......, IRET)
  516.  
  517. to
  518.  
  519.      addvect (......, CURRENT)
  520.  
  521. Seems to work better!
  522.  
  523. As for packet driver fixes.... Since I am not using any packet driver code
  524. I will pass the torch to others                 ;-)
  525.  
  526.  
  527. 73 from Brian A. Lantz      KO4KS@KO4KS.#TPAFL.FL.USA.NA    3100813105
  528.                   Internet: brianlantz@delphi.com
  529.                    Amprnet: ko4ks@ko4ks.ampr.org         [44.98.0.167]
  530.  
  531. ------------------------------
  532.  
  533. End of TCP-Group Digest V93 #9
  534. ******************************
  535. ******************************
  536.